Location of a branch office. UN/Locode; e.g. the location of the user's branch office. If there is no UN/LoCode available for this place, alternatively the name can be set. Communication data, e. g. the message's creation time or sender, recipient Up to 11 entries can be sent: SENDER - mandatory with DAKOSY-code RECIPIENT - mandatory with DAKOSY-Code. Maximum of nine entries is possible. EDI_PROVIDER Date and time of message creation. Format : 1999-05-31T13:20:00 Use local time. Value will be read "as it is". Please do not send an offset from the UTC. plain text without validation. Either phone number or e-mail address must be filled if the user-element is transmitted. Meta information for each message. Contains information concerning transaction type, communication parties etc. Specifies the transaction type (GM01, AB01 etc.). Only one transaction per file is allowed. Different types must be sent in separate files. Name of the application that built the message. unique reference per physical xml-file 0 - false (default); 1- true; transmission for test purpose Number of messages (elements) that are collected in the transmitted file. Code identifying the participant Alias code. Describes how the participant is identified in a system, e.g. DAK as DAKOSY-code. Other identifiers are not specified yet. Code identifying the participant just for informal use Needs only to be set if required by the specified role. Desribes the particpant's communication part as the message's sender, it's recipient etc. Required entries: RECIPIENT SENDER EDI_PROVIDER name of the party who is responsible for the underlying scheme. Code defined by the provider for the specified transaction. Single type which is represented by this file. A Transaction identified by its code may contain several types identified by their type. This hierarchy is known from EDIFACT-messages where e. g. the transaction GM01 (code) consists of CUSCAR and APERAK (type). Version of message definition